1. Field of the Invention
The present invention pertains to asynchronous formatters and more particularly to asynchronous formatters which convert packets in CCITT X.25 format into a proprietary format adopted to PCM switching.
2. Background of the Invention
Currently intelligent data networks are based on a transmission technique known as packet switching. These data networks employ special purpose communication switching minicomputers, typically interconnected with leased lines to carry user data from the user source location to its destination.
In general the data messages from users of the network are accepted by the network minicomputers, which assemble them into fixed length segments called packets. The packets are then transmitted through the network in a store and forward fashion to their destination. Each packet is individually handed forward along the best available path and is error checked each time another link is traversed. Complete messages are then reassembled from their constituent packets at the minicomputer which interfaces with the destination user site.
Since many of these intelligent data networks are offered by common carriers a standardized software dependent interface must be employed. The software interface offered on most of these public networks is that defined by its CCITT (Consultative Committee for International Telephone and Telegraph) and known as the X.25 interface. The X.25 defines the procedures for the packet assembly and disassembly between the terminal and the packet switching network. The procedures for this handling of these packets within the switching network are called the network level protocol. This intra network protocol is not CCITT standard and is usually different on each network. Packet formats in the X.25 protocol involve the formats of data and control packets, in general the formats of X.25 packets all contain four (4) basic fields:
General Format Indicator
Logical Channel Identification Number
Packet Type Identifier
Information Field
General Format Indicator the first header field is the general format indicator. The primary purpose of the general format indicator is to specify the format of modulo number (modulus) being used for this packet. Logical Channel Identification Number. Every control and data packet must contain a two-part logical channel identification number. It consists of a logical channel group number in four bits of the first byte of the packet header, and an eight-bit logical channel number that takes up the entire second byte of the packet header.
The logical channel numbers constitute a numbering scheme that is local to the user machine and its network interface. The two users involved in a virtual call or a permanent virtual circuit will probably use different logical channels numbers for their connection with their local Data Circuit Equipments (DCEs). In the initial setup procedure for a virtual call, the network makes an association between the real addresses of the user machines and their logical channel numbers. Then, during the progress of the call, the network itself has to add additional addressing information to the logical channel identification numbers carried in the packets in order to identify the user machines. The addition of this addressing information is left to the network implementor and does not concern the user of the user/network interface.
Packet Identifier. The third byte of a packet header is known as the Packet Type Identifier. The Packet Type Identifier describes the function of the packet being transmitted. The packet information field following the packet identifier will provide additional packet header information depending upon the function of a control packet or it will contain the user data if it is a data packet.
Call request packets. The call request packet normally contains the network address of the destination device and may contain the address of the originating device. Both addresses are variable in length so that long addresses could be used if necessary. These addresses are located in the first bytes of the information field of the Call Request packet. Each digit of the address is encoded in a half-byte of the address field. The address field is preceded by two half-bytes that state how many digits are in each address.
The addresses may be followed by a facilities field, which is also of variable length. This field is present when the originating machine wants to make a call with some optional characteristics that must be communicated to the destination machine. Recommendation X.25 specifies several such options. A calling party might indicate that the called party is to pay for the call. A maximum data length might be requested because of limited buffer size. A specific flow control might be requested. The CCITT permits all of these options and allows for other optional facilities that might be added in the future. For each optional facility requested, the facilities field contains two bytes. The first byte indicates the type of facility requested. The second byte contains a parameter associated with the request: for example, maximum data length.
The Incoming Call packet that travels from the second data circuit terminating equipment to the called data terminating equipment has the same format as the Call Request packet and carries most of the same information. The called data circuit terminating equipment, however, must select its own logical channel numbers, so the logical channel group number and the logical channel number will be different in the Incoming Call packet and the Call Request packet.
To complete the virtual call connection, the called data terminating equipment sends a Call Accepted packet to its data circuit terminating equipment, which is forwarded to the calling data terminating equipment in the form of a Call Connected packet. The Call Accepted/Call connected packet has a relatively simple format, since the optional facilities have already been decided on and the network addresses were carried in the Call Request/Incoming call packet. All the information it needs to carry is contained in the three-byte header.
Before the calling party initiates the virtual call, the logical channel is in a ready state. After the Call Request packet has been passed from the data terminating equipment to its data circuit terminating equipment, the logical channel is in the data terminating equipment waiting state. When the called data circuit terminating equipment passes the incoming Call packet to the called data terminating equipment, the logical channel is placed in the data circuit terminating equipment waiting state. When the called data terminating equipment returns the Call Accepted/Call Connected packet, the logical channel is placed in the data transfer state, and normal data transmission can begin. The virtual call has been set up.
Data Packets. When set data packet is indicated, the bits of byte 3 are broken into three (3) subfields:
(1) A packet receive sequence number (R)
(2) A more-data bit
(3) A packet send sequence number (S)
The functions of the packet receive sequence number and send sequence number are similar to the sequencing performed at the frame level in HDLC. The packet seqeence numbers through are independent and will have different values from the link layer numbers.
Data packets for each virtual call are sequenced at packet level. Each data packet contains a Packet Send Count P(S), which will advance with succeeding data packets, and a Packet Receive Count P(R), which will indicate the next expected data packet.
Note that the sequence numbering N(S) and N(R) at the frame level is used to sequence and authorized all 1-frames at the ling level. The sequence numbering P(S) and P(R) at packet level is used to sequence and authorize data packets for a virtual call in the packet network.
The M bit of the third byte of a data packet header is called the More-data bit. When this bit is set to 1, it indicates that more of the same user data record follows in the next sequential packet. The More-data bit can only be set in a packet that contains the maximum allowable number of data bits. Although the CCITT recommends that the maximum data field length be 128 bytes, it does state that some telecommunications administrations may support other maximum data lengths: 16, 32, 64, 256, 512, or 1,024 bytes, or, exceptionally 255 bytes. In this case, data packets may have to be split or combined as they pass from one network to another. The More-data bit would be used to facilitate this splitting and recombination.
In this discussion of the third byte packet, we have dealt exclusively with transmission using modulo 8 counts. As we said earlier however, the CCITT allows the use of modulo 128 counts. When the general format identifier indicates that modulo 128 counts are being used for a data packet, three bits are not enough to specify either a send sequence number or a receive sequence number. In these cases, a fourth byte in the header is used to extend each of the sequence number fields by four bits.
Most current networks are being implemented with modulo 8 numbering. However, modulo 128 numbering will probably be employed when satelite links are used and when traffic volumes build up.
For data transfer during a typical data transmission over a permanent or temporary virtual circuit, three (3) types of packets may be used:
(1) Data Packets
(2) Receive Ready packets
(3) Receive Not Ready packets
The logical channel remains in the "data transfer" state throughout the data transmission.
Once a virtual circuit has been established, users can transmit data back and forth in Data Packets.
If both user machines on a virtual circuit are sending data, the receipt of data packets can be acknowledged by piggybacking the receive sequence numbers on returning data packets. If only one machine is transmitting data however, the receipt of data packets must be acknowledged by special control packets.
A Receive Ready control packet is used to indicated willingness to receive a given number of packets and to acknowledge the correct receipt of data packets already transmitted. The Receive Ready packet carries a three-bit receive sequence number in the third byte of its packet header. These packets carry no send sequence numbers and no information field.
If a user machine is temporarily unwilling or unable to receive further data packets, it returns a Receive Not Ready packet to the other user machine. Like the Receiver ready packet, this packet carries a receive sequence number but no send sequence number. A Receive Not Ready packet acknowledges the correct receipt of data packet, and causes the other user machine to temporarily suspend its data transmission. When a user machine is once again ready to receive data, it sends a Receive Ready packet to the other user machine, and the data transmission is resumed.
Virtual Call Disconnect. A virtual call may be disconnected at the request of either user, or, in special cases, at the request of the network. Three (3) different packet types and four (4) different logical channel states may be involved in this termination process. These packet types and channel states are listed below: